feat: add OpenTelemetry feature into Gravitee Node #374
Conversation
guillaumelamirand
force-pushed
the
archi-401-opentelemetry
branch
4 times, most recently
from
26c1990
to
53eee18
Compare
guillaumelamirand
force-pushed
the
archi-401-opentelemetry
branch
9 times, most recently
from
7f12533
to
6b45634
Compare
BREAKING CHANGE: Tracing plugin has been removed and is now embedded inside node framework
guillaumelamirand
force-pushed
the
archi-401-opentelemetry
branch
from
6b45634
to
8da7990
Compare
| this.environment = environment; | ||
| } | ||
|
|
||
| @Value("${services.opentelemetry.enabled:${services.tracing.otel.traces.enabled:true}}") |
There was a problem hiding this comment.
I can see that the services.opentelemetry.enabled is set to false by default in the gravitee.yaml of APIM which avoids to fallback to the services.tracing.otel.traces.enabled value.
Also, I can't remember where services.tracing.otel.traces.enabled comes from. Can you confirm (or not) that it isn't services.tracing.enabled instead?
| @@ -0,0 +1,26 @@ | |||
| /* | |||
| * Copyright (C) 2015 The Gravitee team (http://gravitee.io) Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. | |||
There was a problem hiding this comment.
Looks like the license header is broken
| @@ -0,0 +1,15 @@ | |||
| /* | |||
| * Copyright (C) 2015 The Gravitee team (http://gravitee.io) Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. | |||
| * @author Guillaume LAMIRAND (guillaume.lamirand at graviteesource.com) | ||
| * @author GraviteeSource Team | ||
| */ | ||
| public record ObservableHttpServerRequest(HttpServerRequest httpServerRequest) implements ObservableHttpRequest { |
There was a problem hiding this comment.
I'm wondering if it should not be moved into the node-vertx instead (assuming it doesn't cause any trouble)?
Same question for other records.
| <gravitee-kubernetes.version>3.1.0</gravitee-kubernetes.version> | ||
| <snakeyaml.version>2.0</snakeyaml.version> | ||
| <hazelcast.version>5.5.0</hazelcast.version> | ||
| <gravitee-alert-api.version>1.9.1</gravitee-alert-api.version> | ||
| <opentelemetry.version>1.39.0</opentelemetry.version> |
There was a problem hiding this comment.
There is a most recent version (1.43.0)
| } | ||
|
|
||
| private SpanExporter createGrpcSpanExporter(final URI tracesUri) { | ||
| return new VertxGrpcSpanExporter( |
There was a problem hiding this comment.
I remember you presented this part during a live session but I'm afraid I forgot the reasons behind the implementation of the VertxGrpcSpanExporter.
I did a quick test using OtlpGrpcSpanExporter provided by opentelemetry and it does the job so I'm wondering if we should give it a try (it would save us from a lot of copy-pasted code that are kind of complex and will probably be hard to maintain).
For the record, here is how I quickly tested it:
private SpanExporter createGrpcSpanExporter(final URI tracesUri) {
return OtlpGrpcSpanExporter
.builder()
.setEndpoint(openTelemetryConfiguration.getEndpoint())
.setCompression(openTelemetryConfiguration.getCompressionType().value())
.setTimeout(openTelemetryConfiguration.getTimeout())
.setHeaders(this::populateTracingExportHttpHeaders)
.setMeterProvider(MeterProvider::noop)
.build();
}| @@ -0,0 +1,23 @@ | |||
| /* | |||
|
|
||
| SdkTracerProvider tracerProvider = SdkTracerProvider | ||
| .builder() | ||
| .addSpanProcessor(BatchSpanProcessor.builder(exporterFactory.createSpanExporter()).build()) |
There was a problem hiding this comment.
As the span exporter establishes connections and deals with batching, I'm wondering if we could find a way to share it instead of creating one for each tracer. This could save resources (connections, workers, ...). It comes with an extra effort to manage its lifecycle which, according to the javadoc, it is tight to the tracer's lifecycle but worth the pain. WDYT?
| @@ -0,0 +1,129 @@ | |||
| <?xml version="1.0" encoding="UTF-8"?> | |||
There was a problem hiding this comment.
As it is a new node module, can you add a readme similar to what has been done for cluster or cache 🙏 ?
Issue
https://gravitee.atlassian.net/browse/ARCHI-401
Description
The objective is to provide a generic way for Gravitee Application to manage tracing based on OpenTelemetry specification.
Additional context
Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:
7.0.0-archi-401-opentelemetry-SNAPSHOT